1. Field of the Invention
This invention relates generally to transaction auditing for data security devices of the type which store user data and can interact with terminal devices to provide information about the stored user data to the terminal devices. Data security devices enabling reliable auditing of these transactions are provided, as well as terminal devices for use with such security devices, systems employing these devices, and computer programs for controlling operation of such devices.
2. Description of the Related Art
There are numerous scenarios in which a user needs to prove certain information in order to access some resource. This information is often security-sensitive in that it may be secret, private, personal or otherwise deemed worthy of protection against unauthorised disclosure. Such information can be stored as user data in memory of a data security device which is adapted to interact with a terminal device. The security device can provide information about the stored user data to the terminal device so as to prove whatever information is required in order to access the resource in question. On successful proof, the terminal device permits user access to the resource.
A smart card is a common form factor for such a data security device. Examples include electronic identity (eID) cards, credit cards, healthcare and insurance cards. The user data stored on the card is typically protected in some way, e.g. by a cryptographic encoding process, both to protect against unauthorised access and to provide assurance of validity. In particular, user data is commonly encoded in a cryptographic construction, in particular some form of cryptographic credential, which is issued by a trusted authority who has verified the information represented by the user data. In an attribute-based system for instance, items of user information are represented by values assigned to predefined “attributes”, these being defined according to the information to be proved, for example specifying city of birth, age, profession, hair colour, and so on. The attribute values can be encoded as user data in the credential to certify the correctness of the information represented. For security purposes, credential systems are ideally designed so that proofs can be made about stored user data without revealing anything other than that which is to be proved. Hence, a terminal device requesting proof of some particular information about the stored user data can obtain the required proof without learning anything else about the user data.
When interacting with a data security device, the terminal device sends the security device a request specifying the information required about the stored user data. In attribute-based systems, for example, this specification, or “policy”, indicates any attribute values which need to be disclosed and/or what needs to be proved about particular attribute values. The security device then engages with the terminal in a cryptographic proof demonstrating possession of a valid credential certifying user attributes satisfying the policy.
Reliable auditing of the information exchanges between a terminal and security device is problematical. In particular, it is desirable for a user to be able to check the information which is requested by terminals in his various transactions, but obtaining reliable audit information for this purpose is not straightforward. Various factors contribute to this problem. For example, typical data security devices, like smart cards, generally do not have their own user interface. Hence, these devices cannot display audit information to the user transaction by transaction. While terminal devices usually do provide a user interface, these devices are generally untrusted and so cannot be relied on by the user to present audit information honestly. In particular, an untrusted terminal might ask the security device many questions about its user data without informing the user about these interactions. The terminal might then be able to infer confidential user data from all these transactions. For example, if a security device offers proof of age by age range (e.g. “I'm older than 18”, or “I'm younger than 16”, etc), then the terminal might infer the actual certified age of the user, or even the actual date of birth, from many requests with different age policies. Without a user interface of its own the security device cannot inform the user directly of this misuse.
Another difficulty is that persistent memory in data security devices like smart cards has limited re-writability. This makes it impractical for the security device to record its own audit trail of the user's transactions. For example, the EEPROM (electrically erasable programmable read only memory) employed in current eID cards is limited to of the order of 10,000 write operations (due to wear-out caused by inherent erase cycles). In fact, eID card functionality ideally avoids write operations to EEPROM wherever possible. This is partly because the cards are designed to refuse service completely if even a single EEPROM cell is broken, and there have been cases in which eID cards have expired much too early due to excessive write operations.
Volatile memory in a data security device may of course record details of terminal abuse involving multiple undisclosed requests. However, as the device's volatile state is deleted with each power loss, the terminal can reset the volatile state of the device and so delete even the volatile record of misuse.
It will be seen from the above that data security devices tend to be at the mercy of the terminal device as far as audit information is concerned, and are consequently vulnerable to multiple-request attacks of which the user is oblivious. This fundamental limitation is particularly significant if the security device can respond in multiple ways to terminal requests, with each response disclosing additional information about the user. A terminal can then escalate its knowledge about the user by asking many undisclosed questions. It has been proposed to certify terminal devices such that they are only allowed to request certain attributes. However, this only restricts the attribute space in which the terminal operates and does not prevent the terminal from escalating its knowledge to the boundaries of this space, even if the broader transaction actually required much less knowledge. Another option is to use trusted terminals, or trusted hardware devices for monitoring terminal operation, which incorporate a trusted user display and input.